WHY: CodeRabbit threads on PR #2 flagged 7 findings inside the vendored
  ziglint copy; the fixes landed upstream (EugOT/ziglint#4) — patching
  the package cache in-place would desync it from its content hash.
WHAT: build.zig.zon repinned to main@a2fa56a (hash t0bwLzCwBQA...);
  vendored zig-pkg snapshot refreshed, stale t0bwLz2XBQC... removed.
  Upstream brings: Config.deinit + pub Rule re-export, doc-comment
  qualifier scan (pub inline fn), strict doc-test gate, alias-recursion
  cap, user_type no longer coerced to std_type, findProjectRoot
  caller-allocator fix.
IMPACT: zigdoc lint gate now runs the hardened ziglint.
VALIDATION: mise x zig@0.16.0 zig build test --summary all => all steps
  green (tests, zig fmt --check, ziglint self-lint via new pin).

* Update for Zig 0.16

* fix: complete zig 0.16 quality gates

* fix(zigdoc): address PR #2 review — escape JSON paths, propagate build-runner failures, plug initProject leak

WHY: Review on #2 (Codex P2 ×2, Copilot ×1) flagged correctness + resource
  issues that let malformed input or build failures masquerade as missing docs.
WHAT:
  - build_runner_0.16.zig: encode module/import names and root paths via
    std.json.Stringify.encodeJsonString instead of raw "{s}" interpolation,
    so Windows backslash paths (C:\...) no longer emit invalid JSON that
    breaks parseBuildOutput.
  - main.zig processBuildZig: return error.BuildRunnerFailed (with stderr) on
    non-zero build-runner exit instead of silently continuing with zero modules.
  - main.zig initProject: cap run() stdout/stderr at .limited(1MiB) and free the
    caller-owned buffers (was leaking on success path).
  - Walk.zig: migrate StringArrayHashMapUnmanaged -> array_hash_map.String (0.16).
  - build.zig.zon: repoint ziglint dep ref fix/0.16-build-compat -> main.
IMPACT: zigdoc module discovery on Windows and on failing builds; no public API change.
VALIDATION: mise x zig@0.16.0 zig build test --summary all => 13/13 steps,
  15/15 tests, zig fmt --check clean, ziglint self-lint gate clean.

* fix: lift PR 2 flake and runner to Zig 0.16

* chore(deps): bump ziglint to a2fa56a (review-hardening release)

WHY: CodeRabbit threads on PR #2 flagged 7 findings inside the vendored
  ziglint copy; the fixes landed upstream (EugOT/ziglint#4) — patching
  the package cache in-place would desync it from its content hash.
WHAT: build.zig.zon repinned to main@a2fa56a (hash t0bwLzCwBQA...);
  vendored zig-pkg snapshot refreshed, stale t0bwLz2XBQC... removed.
  Upstream brings: Config.deinit + pub Rule re-export, doc-comment
  qualifier scan (pub inline fn), strict doc-test gate, alias-recursion
  cap, user_type no longer coerced to std_type, findProjectRoot
  caller-allocator fix.
IMPACT: zigdoc lint gate now runs the hardened ziglint.
VALIDATION: mise x zig@0.16.0 zig build test --summary all => all steps
  green (tests, zig fmt --check, ziglint self-lint via new pin).

---------

Co-authored-by: Tim Culverhouse <tim@timculverhouse.com>

…w DoS) (#5)

* fix(TypeResolver): bound nodeIsTypeRef alias recursion (stack-overflow DoS)

WHY: ziglint analyzes untrusted source. The nodeIsTypeRef / varDeclIsTypeRef /
identifierIsTypeRef trio recursed with no depth guard, so a cyclic alias such as
`const a = b; const b = a;` (or self-referential `const a = a;`) in any linted
file caused unbounded recursion and a stack-overflow crash. PR #4's "harden
resolver" added max_alias_depth=32 but only to findMethodInFileAsStructDepth,
missing this sibling family. (Pre-existing upstream; introduced by upstream
6b11b20.)

WHAT: Thread a `depth: u32` parameter through nodeIsTypeRef (via new
nodeIsTypeRefDepth), varDeclIsTypeRef, identifierIsTypeRef, and
fieldAccessIsTypeRef, incrementing on each recursive hop and returning false once
depth >= max_alias_depth. Public isTypeRef() entry starts at depth 0. Mirrors the
existing findMethodInFileAsStructDepth guard pattern. Added regression tests:
cyclic alias, self-referential alias (both via isTypeRef), and a cyclic method
alias (via findFnInCurrentModule, locking in the pre-existing guard).

IMPACT: src/TypeResolver.zig only. No behavior change for non-cyclic input; the
32-hop cap is far beyond any real alias chain. Eliminates a remotely triggerable
linter crash on adversarial source.

VALIDATION: New tests crash (10001-frame stack overflow) before the fix and pass
after. `zig build test --summary all` -> 7/7 steps, 277/277 tests pass, zig fmt
clean, self-lint (run exe ziglint) clean. Found via multi-agent audit of the fork
diff (bfcb30d..main) with adversarial verification.

* fix(TypeResolver): count one depth increment per alias hop

WHY: CodeRabbit and Copilot both flagged that the alias-recursion guard
incremented depth twice per logical hop (identifierIsTypeRef ->
varDeclIsTypeRef(depth+1) -> nodeIsTypeRefDepth(init, depth+1)), so
max_alias_depth=32 effectively capped at ~16 alias links and could false-negative
on long but acyclic alias chains.

WHAT: identifierIsTypeRef now passes `depth` (not depth+1) into varDeclIsTypeRef;
the single increment stays at the actual alias-following recursion in
varDeclIsTypeRef. One alias link now costs exactly one increment, matching the
intended "~32 hops". Termination is unchanged (every cycle still passes the
incrementing call).

IMPACT: src/TypeResolver.zig only. No safety change (still terminates, no
overflow); removes a false-negative risk for deep legitimate alias chains.

VALIDATION: zig build test --summary all -> 7/7 steps, 277/277 tests pass, fmt
clean, self-lint clean. Cyclic/self-referential alias regression tests still pass.